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I.   INTRODUCTION 


The  Naval  Postgraduate  School  Signal  Processing  and 
Display  Laboratory  [1]  is  used  for  research  and  education  in 
the  areas  of  operating  systems*  computer  graphics*  signal 
processing  and  hybrid  computing.  The  laboratory's  eauiDment 
configuration  is  illustrated  in  Fig.  1 .  The  system  is  built 
around  two  Digital  Equipment  Corooration  PDP-11/50 
processors  that  share  some  memory*  some  peripherals*  and 
access  to  a  signal  processing  subsystem  consisting  of  a 
Computer  Signal  Processors  Incorporated  CSP  125  controller 
with  an  array  processor  and  an  analog  to  digital  converter. 
The  peripheral  suite  may  be  divided  into  two  major  groups: 
the  data  acguisition  group  and  the  display  group.  The 
display  group  consists  of  dynamic  graphics  disolay  units 
that  are  designed  to  support  real-time*  interactive 
apDl i cat i ons .  The  data  acquisition  grouo  consists  of 
terminals*  disks*  tapes*  and  unit  record  equipment  that 
serve  the  dual  purposes  of  supoorting  a  healthy  environment 
for  program  development  and  providing  for  the  acquisition  of 
data  for  the  graphics  and  signal  processing  applications. 

Choosing  an  operating  system  for  the  laboratory 
presented  significant  challenges.  Traditionally*  real-time 
operating  systems  have  provided  poor  environments  for 
program    development.    The    operating   systems   that  are 
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responsive  to  the  aemands  of  orogram  development  have 
provided  very  poor  real-time  and  interactive  environments. 
When  the  equipment  was  acauired,  no  single  PDP-11  operating 
system  met  all  the  needs  envisioned  for  the  laboratory.  It 
would  not  have  been  surprising  if  the  decision  had  been  made 
to  support  separate  operating  systems  tailored  to  the 
demands  of  the  two  areas.  Because  of  the  difficulties 
inherent  in  maintaining  and  scheduling  multiple  operating 
systems  on  one  computer  system,  it  was  decided  to  attempt  to 
develop  a  unified  operatinq  system  having  specialized 
subsystems  to  support  both  foreground  real-time/  interactive 
processing  and  background  program  development  processing. 

The  baseline  ooerating  system  selected  was  UNIX,  a 
time-sharing  system  develooed  at  Bell  Laoo ra t o r i es .  One  of 
the  imoortant  advantages  of  UNIX  was  that  source  code  in  a 
high  level  language  was  furnished  with  the  system.  The 
availability  of  source  code  and  UNIX's  excel  lent  suDPort  for 
program  development  promised  a  climate  favorable  to  the 
anticioated  system  moo i f i ca t i ons  . 

The  UNIX  system  has  Droved  to  be  a  good  selection. 
Several  orojects  designed  to  augment  UNIX  are  in  progress  or 
have  been  completed.  One  area  of  particular  concern  has 
been  memory  management.  Figure  1  reveals  that  the  several 
different  types  of  memory  in  the  configuration  present  some 
unusual  memory  management  Droblems;  but  the  figure  does  not 
reveal  the  complex  memory  management  problems  introduced  by 
the    real-time   applications/   esoecially   those   involving 
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direct  memory  access  by  display  devices.  Some  of  these 
oroblems  have  been  aporoached  in  earlier  work  12.]  f  13]  ,  [4], 
One  area  of  interest  that  had  not  been  investigated  prior  to 
this  thesis  was  the  applicability  of  advanced  memory 
management  techniques  to  the  laboratory  operating  system. 
This  area  was  particularly  attractive  because  the  PDP-11/50 
processors  have  a  Memory  Management  Unit  caoable  of 
supporting  relocation*  paging,  and  some  segmentation.'  The 
purpose  of  this  thesis  is  to  present  the  results  of  an 
investigation  into  the  suitability  of  segmentation  and 
paging  in  the  modified  UNIX  operating  evironment  at  the 
Naval  Postgraduate  School  Signal  Processing  and  Display 
Labora t  o  ry . 
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II.   THE  PDP-11/50 


A.   GENERAL  ARCHITECTURE 

The  PDP-11/50  [51  is  a  powerful »  medium  scale/  general 
purpose/  16-bit  minicomputer.  It  is  well  designed  to 
suoport  multiprogramming  or  real-time  aoo 1  i cat i ons .  Its 
features  include  a  priority  interrupt  structure/  two  general 
purpose  register  sets/  and  three  processor  states  (Kernel/ 
Supervisor/  and  User).  Two  of  the  most  imoortant  aspects  of 
the  PDP-11  architecture  are  its  inout/output  scheme  and  its 
dependence  on  orocessor  stacks.  Both  of  these  have 
important  impacts  on  the  memory  management  methods 
considered  in  this  thesis. 

The  most  important  comoonent  of  the  PDP-11  input/outout 
scheme  is  the  UNIBUS.  The  UNIBUS  is  a  high  soeed/ 
bidirectional/  asynchronous  bus  that  connects  the  CPU/ 
perioherals/  and  memory.  Devices  attach  to  the  UNIBUS  with 
hardware  control  and  data  registers  that  have  simulated 
locations  assigned  in  the  uppermost  U,Q9b  words  of  the 
address  space.  This  simplifies  the  programming  of 
peripheral  devices  because  no  special  class  of  inout/output 
instructions  is  required.  Data  and  control  information  is 
entered  into  or  retrieved  from  the  devices'  registers  as  if 
they  were  actual  memory  locations.  The  UNIBUS  can  be 
controlled   either   by   the   CPU   or  by  a  oericheral  device. 
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This  makes  it  possible  for  the  devices  to  access  main  memory 
with  almost  no  processor  intervention.  The  arbitration  unit 
that  assigns  control  of  the  UNIBUS  to  a  requesting  device  or 
CPU  gives  maximum  priority  to  a  direct  memory  access  request 
from  a  peripheral  device.  Because  the  PDP-11/50  does  not 
feature  a  lock  and  key  memory  protection  scheme/  the 
protection  of  the  operating  system  from  DMA  devices  is  a 
significant  memory  management  problem. 

A  PDP-11  stack  is  an  area  of  memory  set  aside  under 
program  control  for  temporary  storage/  subroutine  linkage/ 
and  interrupt  service  linkage.  In  concept/  it  is  a  classic 
"last-in/  first -out"  stack  of  the  tyoe  described  in  ref, 
(61.  Each  processor  state  has  a  register  specifically 
designed  to  be  its  processor  stack  pointer.  The  intructions 
that  are  provided  for  standard  PDP-11  routine  linkage  and 
interrupt  handling  "push"  and  "poo"  parameters/  linkage 
information/  and  status  information/  using  the  current 
processor  stack.  Other  instructions  are  provided  to 
facilitate  stack  manipulation.  Prooerly  used/  stacks 
provide  automatic  nesting  of  subroutines/  reentrancy/  and 
recursion.  They  also  help  to  decrease  the  overhead  that  is 
inherent  in  linkage  and  interrupt  processing.  The  only 
major  disadvantage  of  using  stacks  is  that  prooerly 
controlling  dynamically  growing  and  shrinking  stacks  is  a 
significant  memory  management  problem. 
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B.   MEMORY  MANAGEMENT  FEATURES 

1 .  Concept  s 

Even  though  the  PDP-11/50  computer  has  a  16-bit  word 
length*  its  basic  addressing  logic  uses  an  18-bit  direct 
byte  physical  address.  In  the  PDP-11/50  system's  simplest 
configuration;  the  two  most  significant  bits  of  the  18-bit 
address  are  not  imolemented.  The  address  space  is  limited  to 
32K  words  (32  *  1,024  words).  The  address  space  is  used  to 
reference  up  to  28K  words  of  main  memory  and  the  4K  words  of 
UNIBUS  device  registers.  To  expand  main  memory  beyond  28K 
bytes*  the  PDP-11  Memory  Management  Unit  (MMU)  must  be  added 
to  the  configuration.  This  unit  interprets  16-bit  addresses 
as  virtual  addresses  from  which  it  constructs  18-bit 
physical  addresses.  Up  to  124K  words  of  main  memory  can  be 
made  adaressable  with  the  MMU. 

2.  Address  Formation 

With  the  MMU  installed/  the  PDP-11/50  supports  two 
32K  word  virtual  address  spaces  for  each  of  its  three 
processor  states.  Each  state  has  an  Instruction  Space  (I- 
space)  and  a  Data  Space  (D-space).  Instruction  fetches* 
index  words*  absolute  addresses*  and  immediate  operands 
reference  I-space.  All  other  references  are  to  D-space. 
The  MMU  constructs  physical  addresses  using  the  information 
in  six  sets  of  relocation  and  descriptor  registers.  The  set 
used  depends  on  the  orocessor  mode  and  the  type  of  address 
reference.    These   registers   and  MMu  control  registers  are 
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assigned  simulated  memory  locations  and  may  be  accessed  in 
the  same  way  as  UNIBUS  device  registers.  Each  register  set 
consists  of  eight  Page  Address  Registers  (PARs)  and  eight 
Page  Descriptor  Registers  (PDRs).  Address  formation  is 
shown  in  Fig.  2.  The  MMU  subdivides  each  16-bit  virtual 
address  into  three  fields:  the  displacement  in  block  (DIB), 
bits  0  to  5;  the  block  number  (BN),  bits  6  to  12;  and  the 
active  page  field  (APF),  bits  13  to  15.  The  APF  is  used  to 
select  a  PAR.  The  twelve  low  order  bits,  or  page  address 
field  (PAF),  of  the  PAR  are  added  to  the  BN  to  form  a  12-bit 
physical  page  block  number  (PBN).  The  DIB  is  concatenated 
with  the  PBN  to  form  the  18-bit  ohysical  address.  There  are 
two  very  important  implications  of  this  scheme:  the  basic 
granularity  of  the  memory  is  the  6  4  -  b  y  t  e  block  and  a  page 
may  begin  on  any  block  boundary  in  the  memory.  The  conceot 
of  the  page  frame  is  not  applicable  to  the  PDP-11. 

3  .   Access  Cont  rol 

The  PDRs  are  used  to  control  access  to  pages,  to 
SDecify  their  lengths,  and  to  provide  memory  management 
data.   The  format  of  a  PDR  is  shown  below. 
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Figure  3.   PDR  Format 

The  fields  in  the  PDR  are:  the  access  control  field  (ACF), 
bits  0  to  2;  the  expansion  direction  bit  (ED),  bit  3;  the 
written  bit  (W),  bit  6;  the  accessed  bit  (A),  bit  7;  and  the 
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page  length  field  (PLF),  bits  8  to  14.  Among  access  options 
that  may  be  specified  in  the  ACF  are:  read  only;  abort  on 
write?  read/write/  no  aborts;  and  non-resident/  abort  all 
accesses.  Because  a  page  need  not  be  a  full  128  blocks  in 
length;  the  PLF  and  the  ED  bits  are  used  to  validate  the 
virtual  BN  before  memory  access  is  permitted.  If  the  ED  bit 
is  not  set,  the  PLF  is  the  page  length  in  blocks  minus  one. 
In  this  case/  any  attempt  to  access  this  page  with  a  B N 
greater  than  the  PLF  is  aborted.  The  ED  bit  is  to  be  set 
when  the  page  contains  a  stack  extending  downward  from  the 
upoer  end  of  the  page's  address  range.  If  the  ED  bit  is 
set;  the  PLF  is  128  minus  the  oage  lenath  in  blocks.  In 
this  case;  any  attempt  to  access  this  oage  with  a  BN  less 
than  the  PLF  is  aborted. 

The  MMU  provides  a  mechanism  by  which  a  Kernel  mode 
suoervisory  routine  may  be  invoked  when  a  memory  management 
abort  occurs.  Enough  information  is  preserved  in  MMU  status 
registers  to  describe  the  tyoe  of  abort  and  to  identify  the 
offending  instruction  and  address.  This  feature  could  be 
used  in  a  demand  paged  memory  manager,  for  example;  to 
resolve  oage  faults. 

The  W  and  A  bits  provide  page  reference  data  for  the 
memory  management  software.  The  W  bit  is  set  if  the  page 
has  been  modified  since  the  PDR  was  loaded.  The  A  bit  is 
set  if  the  page  has  oeen  accessed  since  the  PDR  was  loaded. 
Both  bits  are    reset  whenever  the  PDR  is  modified. 
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III.   THE  UNIX  TIME-SHARING  SYSTEM 


A.   CONCEPTS 

UNIX  [7]  is  a  terminal  oriented,  interactive*  time- 
sharing/ operating  system  developed  at  Bell  Laboratories  for 
use  on  the  PDP-11  family  of  minicomputers.  Most  of  UNIX  is 
written  in  "  C ,  "  [8]  a  high  level  language  also  developed  by 
Bell  Laboratories.  A  small  part  of  UNIX  is  written  in  "as," 
[9]  a  Bell  Laboratories  variant  of  the  PDP-11  assembler 
language.  Among  the  most  significant  of  UNIX's  features 
are:  a  hierarchical  file  system,  a  device  independent 
input/output  scheme,  and  mu 1 t i -t ask i ng . 

The  basic  unit  of  work  under  UNIX  is  the  process.  Each 
process  is  an  execution  of  a  program  file  from  the  UNIX  file 
system.  When  UNIX  "bootstraps"  itself  into  memory  at  system 
initiation  time,  it  "handcrafts"  the  first  two  orocesses: 
process  0  and  process  1.  Process  0,  which  may  be  thought  of 
as  an  execution  of  UNIX,  is  the  master  control  process. 
Process  1  sets  uo  the  system?  all  subseauent  processes  are 
descendents  of  process  1. 

All  processes  except  process  0  execute  in  User  processor 
state.  If  a  process  reauires  service  from  UNIX,  it 
communicates  its  request  by  means  of  a  system  call.  System 
calls  are       mechanized   by   use   of   TRAP  instructions  which 
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interrupt  the  processor*  change  the  processor  state  to 
Kernel*  and  cause  the  apororiate  service  routine  to  be 
executed.  When  the  system  call  comoletes*  it  returns  to  the 
calling  process  with  the  processor  in  User  state. 

A  process  creates  descendents  by  use  of  the  "fork" 
system  call.   This  system  call  creates  an  exact  duplicate  of 

the  calling  orocess.   The  new  process  is  referred   to   as   a 

■«. 

child  process  and  the  original  crocess  is  referred  to  as  a 
parent  process.  The  parent  may  continue  to  execute*  perhaos 
creating  more  children*  or  it  may  use  the  "wait"  system  call 
to  suspend  execution  until  its  child  has  completed 
execution.  The  child  may  continue  to  execute  the  same 
program  as  its  parent  or  it  may  invoke  a  new  program  by  use 
of  the  "exec"  system  call.  A  child  may  also  create  children 
of  its  own.  'When  a  child  comoletes  processing*  it 
terminates  by  means  of  the  "exit"  system  call.  Among  other 
actions*  "exit"  notifies  the  parent  of  the  child's  demise. 

Process  1  begins  its  role  as  grandsire  by  creating  one 
child  for  each  terminal  in  the  system.  Each  child  opens  its 
assigned  terminal*  sends  a  message  request inq  a  user  to  log 
in*  and  awaits  a  reoly .  When  a  user  successfully  comoletes 
the  log  in  procedure*  the  child  invokes  a  new  program  called 
the  Shell.  The  Shell  interprets  commands  specified  by  the 
user  and  creates  children  which  invoke  other  Drograms  to 
carry  out  the  user's  commands.  a  hen  the  user  logs  off*  his 
teminal's  Shell  Drocess  terminates.  Process  1*  which  has 
been   patiently   waiting  for  this  to  hapDen*  is  notified  and 
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it  creates  a  new  child  for   the   terminal.    The   new   child 
reopens  the  terminal  and  sends  another  log  in  reauest. 

B.   MEMORY  MANAGEMENT 

In  conceot,  the  UNIX  memory  manager  is  a  relocatable 
partitioned  memory  manager  CIO]  with  swapping  and  limited 
segmentation.  Each  process  has  an  image  that  must  reside  in 
a  contiguous  partition  while  the  processor  is  executing  on 
behalf  of  the  process.  The  image  remains  in  memory  during 
the  execution  of  other  processes  unless  it  must  be  written 
out  (swapped  out)  to  a  direct  access  device  to  satisfy  the 
memory  reguirements  of  a  higher  priority  process. 
Relocation  and  storage  protection  are  accomplished  with  the 
MMU.  When  the  processor  is  executing  on  behalf  of  a 
process*  the  memory  management  registers  are  loaded  so  that 
the  process  can  access  only  its  own  image  and,  if 
applicable*  a  text  segment  shared  with  other  processes. 
Because  a  process  executes  in  User  mode*  its  adaress  space 
is  the  User  address  space;  however,  a  part  of  the  process's 
image  called  the  UVECTOR  is  established  in  Kernel  D-space. 
The  UVECTOR  contains  process  status  information  needed  by 
UNIX  and  the  Kernel  mode  processor  stack  to  be  used  while 
the  process  is  active.  Not  all  process  control  information 
is  located  in  the  UVECTOR.  Information  that  must  remain 
addressable  even  when  the  process  is  not  executing  remains 
resident  for  the  life  of  the  process  in  Kernel  D-soace  in  a 
control  block  called  a  PROC.   If  the  process  shares  its  text 
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with  other  processes*  its  PROC  contains  a  pointer  to  yet 
another  control  block  resident  in  Kernel  O-space.  This 
control  block  is  called  the  TEXT.  It  contains  information 
that  UNIX  uses  to  control  the  sharing  of  the  text  segment. 
APPENDIX  A  contains  detailed  information  on  the  UVECTOR, 
PROC,  and  TEXT. 

A  process's  image  is  created  when  "fork"  copies  its 
parent's  image.  Whenever  a  process  uses  "exec"  to  invoke  a 
new  program,  the  process's  i maoe  is  recreated  according  to 
specifications  in  the  program  file  to  be  executed.  A 
process's  image  differs  depending  on  whether  or  not  it 
shares  text.  The  image  of  a  text  sharing  Drocess  consists 
of  its  UVECTOR,  data,  and  User  mode  processor  stack.  The 
shared  text  is  established  in  memory  independently  of  the 
images  of  the  processes  sharing  it.  In  the  image  of  a  non- 
sharing  process,  the  text  is  lumped  together  with,  and 
considered  to  be  part  of,  the  data.  If  the  process  shares 
text,  "exec"  checks  to  see  if  a  cooy  of  the  text  is 
available  in  the  system.  If  it  is  not,  "exec"  establishes  a 
cooy  . 

The  User  address  soace  of  a  text  sharing  process  may  be 
established  in  two  different  ways:  seoaratea  instruction  and 
data  spaces  or  combined  instruction  and  data  spaces.  The 
User  address  soace  of  a  non-sharing  process  may  only  be 
established  with  combined  instruction  and  data  soaces.  If  a 
process's  address  soaces  are  combined,  its  I-space  and  D- 
space  are       identical.    A   separation   flag,   determined   by 
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"exec"  from  the  file  tyoe  and  kept  in  the  process's  UVECTOR/ 
controls  the  method  used  to  establish  the  address  space  of  a 
text  sharing  process.  If  a  process's  address  soaces  are 
separated^  its  shared  text  segment  is  addressable  beginning 
at  User  I-space  address  0  and  its  data  is  addressable 
beginning  at  User  D-space  address  0.  If  a  combined  process 
has  shared  text*  its  shared  text  segment  is  addressable 
beginning  at  address  0  in  both  User  I-space  and  User  D- 
space;  and  its  data  is  addressable  beginning  at  the  first  4K 
word  boundary  (page  boundary)  beyond  the  end  of  the  text  in 
both  User  I-space  and  User  D-space.  If  a  combined  process 
does  not  have  shared  text/  its  text  is  addressable  beginning 
at  address  0  in  both  User  I-space  and  User  D-space;  and  its 
data  is  addressable  beginning  at  the  first  word  boundary 
beyond  the  end  of  the  text  in  both  User  I-soace  and  User  D- 
space.  A  process's  stack  is  addressable  extending  downward 
from  the  highest  address  in  User  0-SDace  or  in  I-space  ana 
D-space.  The  access  control  SDecified  in  the  PDRs  of  shared 
text  pages  is  read  only.  All  other  pages/  including  non- 
shared text/  are    read-write  access. 

There  are  two  system  calls  that  a  process  may  use  to 
change  the  size  of  its  image  without  invoking  a  new  program. 
These  system  calls  are  "  b  r  k  "  and  "sbrk"  U  1  ]  .  These  are 
used  to  increase  or  decrease  the  size  of  the  Drocess's  data 
area .  They  are  used  mainly  in  programs  with  storage 
requirements  that  have  great  variations  depending  on  input. 
The  size  of  a  process's  image  may  increase  in   another   way. 
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If  its  User  mode  processor  stack  grows  beyond  the  space 
initially  allocated  to  it/  UNIX  dynamically  increases  the 
amount  of  memory  provided, 

C.   INPUT  OUTPUT  SYSTEM 

1.   Standard  Input/Output 

The  UNIX  standard  input/outout  (I/O)  system  112]  is 
designed  to  seoarate  the  user  from  aevice  dependencies/  to 
keep  control  blocks  out  of  the  User  address  space/  and  to 
preserve  process  re  1  oca t ab i 1  i t y .  Two  classes  of  devices  are 
supported  under  the  standard  I/O  system:  character-devices 
and  block-devices.  Character-devices  are  read  and  written 
one  byte  at  a  time  using  a  UNIBUS  device  register  as  an  I/O 
port.  Block-devices  are  read  and  written  in  512  byte  blocks 
using  direct  memory  access  (DMA).  UNIX  Drovides  the 
expected  system  calls  to  create/  open/  access/  and  close 
files  on  both  device  types.  It  also  provides  buffer  areas 
in  Kernel  D-soace  for  character-device  I/O  queues  and  for  a 
pool  of  block  device  buffers. 

When  a  process  requests  a  write  to  a  character- 
device/  an  I/O  supoort  routine  (device  driver  routine)  moves 
the  data  to  the  device's  outout  queue  or  directly  to  the 
device.  »vhen  a  process  requests  a  character-device  read/ 
the  device  driver  receives  the  data  from  the  device  and 
moves  it  to  the  User  address  space. 
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When  a  block  write  is  requested*  the  device  driver 
acquires  a  buffer  from  the  pool  in  Kernel  D-space*  moves  the 
data  from  the  User  adoress  space  to  the  buffer/  and  places 
the  buffer  on  the  device's  output  queue.  when  a  block  read 
is  requested*  the  driver  places  the  request  in  the  device's 
input  queue*  and  acquires  a  buffer  to  which  the  device  will 
transfer  the  data  when  the  request  is  honored.  After  the 
device  has  transferred  the  data  to  the  buffer*  the  driver 
moves  the  data  to  the  User  address  space. 

The  significance  of  standard  I/O  from  the  memory 
management  point  of  view  is  the  way  in  which  it  localizes 
DMA  accesses  to  Kernel  0-soace.  This  is  imoortant  because  a 
DMA  device  must  be  given  the  ohysical  address  of  the  area 
from  which  or  to  which  the  data  will  be  transferred.  In 
Kernel  D-space*  virtual  and  ohysical  addresses  are 
identical.  All  addresses  used  to  move  data  between  the  User 
address  space  and  the  Kernel  D-space  are  virtual;  no  device 
or  routine  needs  to  know  the  physical  address  of  the 
requesting  process's  I/O  area.  This  means  that  standard  I/O 
is  completely  compatible  with  dynamic  relocation  of  the 
requesting  process. 

2.   Raw  Block-device  Input/Output 

Raw  block-device  I/O  [12]  is  a  scheme  whereby  I/O 
takes  place  directly  between  the  requesting  process's  memory 
and  the  device.  The  advantages  of  this  tyce  I/O  are  that  it 
allows   the   use  of  blocks  larger  than  512  bytes  and  that  it 
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avoids  the  overhead  of  movinq  the  data  between  the  User 
address  space  and  the  Kernel  D-space.  Although  it  might 
seem  that  the  data  movinq  overhead  would  be  small,  this  is 
not  the  case  because  the  PDP-11  lacks  a  block-move 
instruction.  The  only  way  to  move  a  group  of  data  words  is 
with  a  prooram  loop.  This  means  that  several  instructions 
must  be'fetched  and  executed  to  move  each  word  of  data  or, 
in  some  cases,  to  move  each  byte  of  data.  The  major 
disadvantaqe  of  this  type  of  I/O  is  that  the  block-device 
must  be  given  the  physical  address  of  the  input  or  output 
area  in  the  User  address  space!  thus,  the  requesting  process 
must  be  "locked"  in  memory  during  the  I/O  operation.  This 
prevents  the  memory  manager  and  process  controller  from 
making  optimum  use  of  system  resources. 

In  practice,  raw  I/O  does  not  have  an  important 
effect  on  operating  system  performance  because  it  is  very 
rarely  used.  It  is  important  because  future  applications 
will  use  it  and  because  supporting  it  presents  some 
difficult  memory  management  problems. 
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IV.   MEMORY  MANAGER  DESIGN 


A.   SEGMENTATION 

The  fundamental  problem  addressed  in  this  thesis  is  a 
pragmatic  one:  how  best  to  modify  the  UNIX  memory  manager  in 
order  to  make  more  complete  use  of  the  capabilities  of  the 
available  memory  management  hardware.  Shared  text  is 
already  well  segmented  in  UNIX,  so  the  first  step  taken  was 
determining  a  good  method  of  dividing  the  process  image  into 
segments.  The  important  considerations  were  that  the 
segments  be  logically  seoarate  and  i  naependen  t  1  y  managable 
in  main  memory.  It  Droved  to  be  possible  and  desirable  to 
use  the  natural  division  already  discussed:  U  V  E  C  T  0  R  ,  data 
(including  non-shared  text)/  and  the  User  Drocessor  stack. 
This  division  has  the  apoeal  of  being  straightforward  and  of 
being  an  efficient  wav  of  cooing  with  the  problem  of 
managing  the  dynamic  size  changes  of  the  data  and  stack 
areas . 

A  study  of  the  UNIX  system  showed  that  reestablishing 
the  process  image  when  the  data  or  stack  changes  size  is  a 
major  source  of  memory  management  overhead.  Whenever  either 
the  stack  or  the  data  changes  size,  the  UNIX  memory  manager 
has  to  acguire  memory  for  an  entire  new  image  and  copy  the 
UVECTOR,  aata,  and  stack  to  it.  The  cost  of  this  copying  is 
about  10  micro-seconds  of  orocessor  time  oer  word  if   memory 
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is  available  for  the  new  image*  and  several  seconds  of 
elapsed  time  if  memory  has  to  be  acquired  by  swapping  other 
processes  out  of  memory.  If  changing  size  were  an 
infrequent  occurrence/  this  cost  would  not  oe  excessive  but 
studies   have   shown   that   some   of   the  most  commonly  used 
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Drograms  change  size  often.  Among  these  programs  are:  cc 
the  "C"  language  compiler;  "ed*"  the  text  editor;  and  "as/ 
the  assembler.  With  the  data  and  stack  in  "  seoarate 
segments*  overhead  is  reduced  because  only  the  segment  that 
changes  size  has  to  be  copied.  If  the  segments  were  divided 
into  Dages/  only  the  last  page  of  the  segment  would  have  to 
be  copied*  reducing  overhead  even  more. 

There  is  another  imoortant  reason  for  establishing 
separate  segments  for  the  data  and  the  stack.  Several 
applications  CI]  planned  for  the  Signal  Processing  and 
Display  Laboratory  will  require  a  memory  manager  that  can 
place  a  process's  data  segment  in  a  specific  area  of  main 
storage.  Specific  placement  will  be  required  to  reduce  the 
overhead  of  orocessor  to  processor  and  processor  to  device 
communication  and  to  orotect  processes  from  aestruction  by 
errant  operations  by  DMA  devices.  An  example  is  a  process 
that  reauires  the  CSP  125  array  processor.  The  CSP  125  can 
access  only  a  portion  of  the  memory  available  in  the 
laboratory  system.  Any  Drocess  that  communicates  with  the 
CSP  125  must*  therefore*  have  its  data  segment  olaced  within 
the  memory  that  the  CSP  125  can  access. 
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Another  example  is  a  real-time  graphics  orocess  using 
the  Vector  General  3D3I  display  unit.  This  DMA  device 
retrieves  and  interprets  its  display  list  forty  times  per 
second.  Instructions  in  the  display  list  can  cause  the 
device  to  store  data  anywhere  within  the  3  2  K  word  memory 
segment  containing  the  list.  To  protect  the  UVECTOR  and 
stack  of  the  process  using  this  device*  the  display  list 
must  be  isolated  in  a  32K  word  memory  segment. 

B.   ALLOCATION  OF  MEMORY 

After  the  method  of  segmentation  was  aecided/  the 
specifics  of  the  memory  allocation  technique  were 
considered.  It  was  assumed  at  first  that  a  paged  segmented 
memory  manager  [131  would  be  the  best  choice.  After  careful 
consideration/  a  partitioned  segmented  memory  manager  was 
chosen.  Partitioned  segmentation  is  a  variant  of  paged 
segmentation  first  suggested  by  Randall  [14]  based  on 
simulation  studies  of  simple  segmentation  and  paged 
segmentation.  The  differences  between  paged  and  partitioned 
segmentation  are:  the  basic  auantum  of  storage  allocated  and 
the  method  of  physical  address  formation  requi  red. 

The  allocation  quantum  in  oaqed  segmentation  is  the  page 
frames  an  area  of  memory  large  enough  to  hold  exactly  one 
virtual  page.  Each  reauest  for  storage  is  the  same  size 
(page  size)  and  each  free  area  is  an  integral  multiple  of 
this  size.  This  strategy  reduces  the  loss  of  storage  due  to 
external   fragmentation   because   no  area    of  free  storage  is 
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ever  too  small  to  satisfy  a  request  for  a  page  of  memory. 
It  also  simplifies  the  memory  allocation  and  deallocation 
primitives  because  they  need  to  respond  to  memory  requests 
of  only  one  size.  The  disadvantage  of  paged  allocation  is 
that  even  a  partial  virtual  page  is  allocated  a  full  page 
frame.  The  unused  memory  in  cage  frames  allocated  to 
partial  pages  causes  a  loss  of  usable  storage  called 
internal  fragmentation. 

The  basic  idea  behind  partitioned  segmented  allocation 
is  the  reduction  of  internal  fragmentation.  A  partitioned 
segmented  memory  manager  allocates  storage  in  a  quantum  that 
is  smaller  than,  but  an  integral  divisor  of,  the  page  size. 
The  largest  contiguous  area  allocated  is  eaual  to  the  page 
size?  but/  when  memory  is  allocated  for  a  partial  page,  only 
the  smallest  number  of  quanta  larger  than  the  size  is 
allocated.  Internal  fragmentation  still  occurs  but  the 
average  loss  per  partial  oage  is  only  half  a  quantum  rather 
than  half  a  page  frame.  There  are  two  disadvantages  of 
partitioned  segmentation:  the  memory  manager  must  be  more 
complex  because  it  must  respond  to  requests  for  a  number  of 
different  memory  sizes;  and  external  fragmentation  will 
occur . 

Physical  address  formation  in  a  paged  segmented  system 
is  simple  because  pages  reside  in  memory  at  physical 
addresses  that  are  integral  multiples  of  the  page  size. 
Because  the  page  size  is  always  chosen  as  a  power  of  two, 
the  ohysical  address  is  formed  from  the  virtual   address   by 
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concatenating  the  virtual  address's  d i so  1 acemen t - i n-page 
with  the  physical  page  frame  number.  In  a  partitioned 
segmented  system*  oages  are  placed  in  memory  at  physical 
addresses  that  are  integral  multioles  of  the  quantum  of 
allocation.  Because  the  quantum  of  allocation  is  chosen  as 
a  power  of  two*  the  physical  address  is  formed  by  adding  the 
physical  page  quantum  number  to  the  virtual  address's 
quant um-w i t h i n-page  and  then  concatenating  the  virtual 
address's  di sp 1 acemen t -w i t h i n-quant um  with  the  result. 

Because  the  PDP-tl/50  mmij  can  support  either  a  paged  or 
partitioned  segmented  memory  manager*  the  important 
consideration  in  deciding  between  the  two  memory  managers 
was:  how  the  loss  of  storage  utilization  caused  by  external 
fragmentation  with  a  partitioned  segmented  memory  manager 
would  compare  to  the  loss  of  storage  utilization  caused  by 
internal  fragmentation  with  a  paged  segmented  memory 
manager.  A  definitive  answer  to  this  question  is  not 
possible  unless  both  memory  managers  are  tested;  however*  it 
is  easy  to  show  that  the  storage  losses  with  a  paged 
segmented  memory  manager  would  be  unacceotaole  in  the  UNIX 
environment.  The  argument  for  this  premise  is  based  on  the 
very  large  C4K  word)  cage  size  imposed  by  the  memory 
management  hardware*  the  extremely  small  number  of  page 
frames  available*  and  the  small  segment  sizes  that  result 
when  the  orocess  image  is  divided  into  three  segments.  The 
most  important  consideration  is  the  comparison  between 
segment  size  and  page  size.   If  the  segments  were  very  large 
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compared  to  the  pages/  the  percentage  of  partial  pages  would 
be  small  and  the  resulting  loss  of  utilization 
insignificant.  If  the  segments  were  small  compared  to  the 
pages*  almost  all  pages  would  be  partial  pages  and  the 
resulting  loss  of  utilization  would  be  high. 

The  UVECTOR  segment  is  fixed  in  length  at  ,5K  words. 
The  initial  stack  segment  allocation  for  all  processes  is 
.64K  words.  Stacks  grow  dynamically/  but  observations  have 
shown  that  this  is  a  rare  occurrence.  Estimates  of  the 
average  sizes  of  the  text  and  data  segments  were  determined 
by  examining  the  program  files  of  70  frequently  used 
programs.  The  mean  text  segment  size  was  determined  to  be 
1.9K  words  and  the  mean  data  segment  size  at  the  start  of 
execution  was  determined  to  be  2.2K.  Data  segments 
frequently  grow  but  the  largest  increase  that  has  been 
observed  is  about  .  5  K  words  for  one  phase  of  the  "  C  " 
compiler.  Even  making  the  generous  assumption  that  average 
combined  data  and  stack  growth  is  .5K,  these  figures  show 
that  the  paged  segmented  memory  manager  would  waste  more 
memory  than  it  used  productively.  It  would  allocate  four 
pages  (16K  words)  for  the  average  shared  text  process  of 
which  an  average  of  5.7K  words  would  be  used. 

The  segment  size  data  is  completely  counter  to 
experience  gained  in  large  scale  computer  systems.  It  was 
completely  unexpected.  Because  the  mean  segment  sizes 
observed  were  all  less  than  a  page/  doubts  were  raised  about 
the   desirability   of   selecting    any    memory    management 
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technique  more  coiddI  icated  than  simple  segmentation.  In 
spite  of  the  doubts,  it  was  decided  to  continue  with 
development  of  a  UNIX  with  a  partitioned  segmented  memory 
manager  CPSUNIX).  It  was  believed  that  this  effort  would 
best  serve  to  explore  all  memory  management  options.  Design 
work  was  started/  however,  on  a  version  of  UNIX  with  a 
simple  segmented  memory  manager  CSUNIX).  SUNlX  was  to  be  a 
fall-back  position  if  the  oerformance  of  PSUNIX  Droved  to  be 
unsatisfactory. 

When  the  partitioned  segmented  memory  manager  was 
chosen,  the  only  remaining  design  Question  was  the  size  of 
the  quantum  of  allocation.  The  64-byte  block,  the  smallest 
quantum  supported  by  the  memory  management  hardware,  was 
selected.  This  choice  was  based  on  the  practical 
consideration  that  it  reguired  no  change  to  the  existing 
UNIX  memory  allocation  and  deallocation  Drimitives. 
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V.   MODIFICATIONS  TO  UNIX 


A.   OVERVIEW  AND  PHILOSPHY 

Modifying  the  UNIX  memory  manager  to  oroduce  PSUNIX  was 
a  formidable  task  that  reguired  writing  aoproximately  500 
lines  of  new  code  and  comprehending  and  modifying  existing 
programs  totaling  more  than  1,800  lines  of  code.  The 
approach  that  was  taken  to  this  oroblem  was  to  avoid  putting 
large  sections  of  new  code  into  existing  orograms.  The  new 
code  that  was  needed  to  support  the  memory  manager  was 
centralized  in  several  small  self-contained  functions 
(primitives).  Wherever  possible,  changes  to  existing 
routines  were  limited  to  removing  calls  to  the  old  memory 
management  primitives  and  replacing  them  with  calls  to  the 
new  memory  management  primitives.  The  goals  of  this 
approach  were  to  make  the  the  general  structure  of  memory 
management  in  PSUNIX  seem  familiar  to  those  who  understood 
the  UNIX  structure  and  to  simplify  debugging  by  localizing 
new  code.   These  goals  were  realized. 

The  changes  made  to  implement  PSUNIX  can  be  divided  into 
five  areas : 

1.  Control  Block  M0g i f j ca t i ons 

2.  Memory  Management  Suoport  Modifications 

3.  Swap  Space  Allocation  Modifications 
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4.  Raw  I/O  Support  Modifications 

5.  SuDport  Program  Modifications 

Each  of  these  areas  is  described  in  a  subsequent  section  of 
this  chapter.  SupDortinq  documentation  can  be  found  in  the 
appendices.  APPENDIX  A  contains  detailed  information  on 
control  blocks  related  to  memory  management.  APPENDIX  8 
contains  detailed  documentation  of  memory  management 
routines  found  in  UNIX,  PSUNIX,  and  the  proDosed  simple 
segmented  version,  SUNIX. 

B.   CONTROL  SLOCK  MODIFICATIONS 

The  only  control  blocks  modified  were  the  PROC  (process 
control)  and  the  TEXT  (shared  text  segment  control).  No  new 
control  blocks  were  added  exceot  cage  tables  which  are 
allocated  in  temporary  storage  and  used  as  work  space  during 
memory  allocation  and  deallocation.  In  UNIX,  the  PROC 
contains  the  size  and  address  of  the  image.  In  PSUNIX,  the 
PROC  was  expanded  so  that  it  could  fulfill  the  same  role  as 
the  MULTICS  [15]  Segment  Mao  Table.  The  image  size  and 
address  were  removed  and  the  segment  sizes  and  cage 
addresses  were  added.  In  both  versions  of  the  operating 
system,  the  TEXT  performs  the  same  function  as  an  entry  in 
the  MULTICS  Active  Segment  Table.  The  onlv  modification 
required  for  PSUNIX  was  the  addition  of  a  page  address 
array.  APPENDIX  A  provides  detailed  information  on  the 
PROC,  TEXT,  and  several  other  control  blocks  that  are 
important  to  memory  management. 
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C.  MEMORY  MANAGEMENT  SUPPORT  MODIFICATIONS 

The  basic  form  of  the  memory  management  modifications 
has  been  presented  in  the  previous  chapter.  APPENDIX  B 
provides  complete  documentation  of  the  new  memory  management 
primitives  under  the  heading  "oage.c."  It  also  Drovides 
documentation  of  the  changes  made  to  existing  UNIX  programs 
that  call  these  primitives.  Functions  of  particular 
interest  are:  "neworoc/  which  creates  a  process's  image  by 
copying  the  image  of  the  process's  parent;  "exec/  which 
recreates  a  process's  image  when  the  process  invokes  a  new 
program;  "xalloc/"  which  establishes  shared  text  segments; 
"expand/  which  changes  a  process's  image  size;  "  s  c  h  e  a  >  " 
which  swaps  processes  into  and  out  of  memory;  " x  f  r  e  e  >  "  which 
removes  shared  text  segments  from  the  system;  and  "exit/1 
which  terminates  processes  and  frees  their  resources. 

D.  SWAP  SPACE  ALLOCATION  MODIFICATIONS 

The  UNIX  method  of  controlling  swao  space  is  to  allocate 
it  to  a  process  when  the  process  is  to  be  swapped  out  and  to 
free  it  as  soon  as  the  process  returns  to  memory.  The 
advantage  of  this  is  that  it  keeps  the  demand  for  swap  space 
at  a  minimum  but  the  disadvantage  is  that  it  requires  an 
allocation  and  a  deallocation  whenever  a  process  is  swapped. 
UNIX  swap  I/O  is  extremely  efficient  because  the  process 
image  is  contiguous  in  memory.  Tnis  allows  UNIX  to  swap  a 
process  with  one  I/O  operation. 
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The  PSUNIX  method  of  controlling  swap  soace  is  to 
allocate  it  to  a  process  the  first  time  the  process  is 
swapped  out  and  to  allow  the  process  to  keep  the  swap  space 
when  it  returns  to  memory.  A  process  loses  its  swap  space 
when  it  terminates  or  when  one  of  its  segments  becomes  too 
large  for  the  space  that  was  allocated.  In  both  versions  of 
the  operating  system/  the  process  is  allocated  a  contiguous 
area  of  swap  space.  This  reduces  the  allocation  overhead. 
PSUNIX  incurs  the  overhead  of  one  I/O  operation  oer  page  in 
the  process's  image.  This  means  that  PSUNIX  has  between 
three  and  four  times  as  much  swap  I/O  overhead  as  UNIX  for 
the  average  process. 

The  programs  concerned  with  swapping  are  documented  in 
APPENDIX  B.  Functions  of  particular  interest  are:  "xswap," 
which  swaps  processes  out  of  memory;  "swap/"  the  swap  I/O 
call?  "pswap/"  a  PSUNIX  function  that  swaps  several  pages  to 
or  from  memory;  and  "prswap/"  a  PSUNIX  function  that  returns 
a  swapoed  process  to  memory. 

E.   RAW  I/O  SUPPORT  MODIFICATION 

As  has  been  described  previously/  raw  I/O  reouires  a  DMA 
transfer  directly  from  or  directly  to  a  process's  address 
space.  The  data  is  transferred  to  or  from  a  contiguous  area 
of  main  memory.  In  PSUNIX  this  presents  a  serious  problem 
if  the  data  area  spans  a  page  boundary  because  the  pages 
will  probably  not  be  contiguous.  The  only  efficient 
solution  to  this  problem  is  to  make  the  pages  contiguous. 
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The  function  M  p  h  y  s  i  o  /  "  which  sets  up  raw  I/O  transfers/ 
was  modified  to  determine  if  each  transfer  spans  a  page 
boundary.  when  a  boundary  spanning  transfer  is  requested/ 
"physio"  calls  "  c  o  n  t  i  g  /  "  a  memory  management  primitive/  that 
reallocates  the  data  and  stack  segments  of  the  requesting 
process  so  that  both  of  them  are  allocated  contiguous 
memory.  The  process  is  also  flagged  as  one  that  reauires 
contiguous  allocation.  Whenever  memory  is  allocated  for  the 
process  in  the  future/  the  segments  are  given  contiguous 
areas  of  storage.  The  process  remains  flagged  until  it 
either  invokes  a  new  program  with  "exec"  or  terminates. 
APPENDIX  B  contains  more  detail  on  this  subject. 

F.   SUPPORT  PROGRAM  MODIFICATIONS 

During  the  course  of  this  thesis  two  program  development 

tools  were  perfected  and  two  program  errors  in  UNIX  commands 

were   encountered   and   corrected.  These    programs    and 

corrections   have   been   documented  elsewhere   and  are    only 
briefly  discussed  here. 

The  program  development  tools  are:  an  assembly  language 
program  to  dump  memory  onto  the  swao  file  without  operating 
system  support  and  a  C  language  program/  CRASHSAV/  to 
retrieve  the  dump  from  the  swao  file  and  place  it  into  the 
UNIX  file  system.  The  dump  program  was  made  part  of  the 
operating  system.  It  was  executed  from  the  system  control 
panel  following  a  system  failure  to  oreserve  the  contents  of 
memory   for   analysis.   This  system  of  taking  and  retrieving 
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complete  memory  dumps  was  extremely  valuable.   PSUNIX   could 
not  have  been  develooed  without  it. 

The  two  proqram  errors  were  discovered  in  "  n  m  ,  "  the 
command  for  printing  symbol  tables  of.  compiled  orogramsr  and 
in  "sysfix,"  the  command  that  adjusts  the  format  of  a  UNIX 
operating  system  image  so  that  it  can  be  "bootstrapped"  into 
memory.  The  errors  were  discovered  because  the  PSUNIX  image 
exceeded  6  <4  K  bytes.  Neither  Drogram  executed  p  r  o  d  e  r  1  y  with 
the  PSUNIX  image  as  data  because  both  programs  used  counters 
that  overflowed  at  64K.  The  problem  was  solved  by 
increasing  the  size  of  the  counters. 
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VI.   PERFORMANCE  STUDY 


A.   EXPERIMENTAL  DESIGN 

A  series  of  exoeriments  was  done  to  determine  the 
relative  performance  of  the  UNIX  and  PSUNIX  versions  of  the 
operating  system  under  a  variety  of  operating  conditions. 
The  elapsed  execution  times  of  standard  streams  of  processes 
(benchmarks)  was  chosen  as  the  metric  for  system 
performance.  Two  benchmarks  were  used:  a  monoprogramming 
benchmark,  8ENCH1;  and  a  multiprogrammina  benchmark,  BENCH2. 
Both  benchmarks  contained  the  same  processes.  Most 
processes  chosen  for  the  benchmarks  are  representative  of 
the  I/O  limited  program  development  environment  but  several 
of  them  (notably  a  "Rings  of  Hanoi"  calculation)  are 
processor  limited.  APPENDIX  C  contains  listings  of  the 
commands  in  BEN CHI  and  8ENCH2.  Reference  [11]  documents 
these  commands. 

The  computer  system  used  to  execute  the  benchmarks  was 
the  "BH  side  of  the  laboratory  configuration  shown  in  Fig. 
1.  The  peripheral  devices  used  were  a  single  terminal  and 
two  1.25  mega-word  RK05  cartridge  direct  access  storage 
devices  (161.  The  file  system  for  the  ooerating  system  was 
mounted  on  one  of  the  RK05  devices.  To  reduce  I/O 
contention,  the  other  RK05  device  was  used  for  swapping 
processes   into   and   out   of   main  memory.   The  main  memory 
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available  in  the  system  was   the   oarameter   varied   in   the 
exper  i  ment  s . 

B.   PRESENTAIOM  OF  RESULTS 

The  timing  data  presented  in  this  section  was  obtained 
by  executing  the  benchmarks  under  control  of  the  "time" 
command  [11].  The  times  are  determined  by  sampling  the 
processor  state  at  a  60  m  rate.  "Real"  time  is  actual 
elapsed  test  time  reoorted  to  the  nearest  second.  "User" 
time  is  the  time  the  processor  spent  executing  instructions 
in  the  User  state.  "Sys"  time  is  the  time  that  the 
processor  SDent  executing  instructions  in  the  Kernel  and 
Supervisor  states.  Both  "User"  and  "Sys"  times  are  reported 
to  the  nearest  tenth  of  a  second.  The  difference  between 
"Real"  time  and  the  sum  of  "User"  and  "Sys"  times  is 
orocessor  idle  time.  Earlier  work  [d]  suggests  that  timings 
of  the  same  benchmark  may  have  a  standard  deviation  of  as 
much  as  8  percent  of  the  mean  values.  No  statistical  study 
of  these  timings  was  performed  in  the  course  of  this  thesis 
but  limited  ooservations  indicate  that  the  deviation  is  much 
less  than  8  percent. 

Six  experiments  were  performed.  The  first  was  an 
execution  of  BENCH1,  the  monoprogramming  benchmark,  under 
both  operating  systems.  The  results  of  this  experiment  are 
shown  in  Table  1.  The  next  five  experiments  consisted  of 
executing  B  E  N  C  H  2  under  both  operating  systems/  varying  the 
amount   of   dynamic   memorv   availible  from  32K  words  to  64K 
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words  in  8K  word  steos.  The  results  of  these  experiments 
are  shown  in  Tables  2  to  6  resDec t i ve 1 y .  Combined  results 
are  shown  in  Fig.  Q ,  a  graph  of  elapsed  times  against 
dynamic  memory  available. 

C.   ANALYSIS  OF  RESULTS 

The  experimental  results  clearly  indicate  that  the 
performance  of  PSUNIX  and  the  performance  of  UNIX  are  almost 
identical  over  a  wide  range  of  sizes  of  available  dynamic 
memory.  Both  the  amounts  of  processor  idle  time  and  of 
supervisory  overhead  are  approximately  egual  in  all 
corresponding  experiments.  The  approximate  egual i  t  y  of  idle 
times  indicates  that  the  aisaavantage  of  increased  swapping 
overhead  in  PSUNIX  is  offset  by  a  reduction  in  the  number  of 
processes  swapped  because  of  reduced  external  fragmentation. 
The  approximate  eauality  of  the  supervisory  overhead 
indicates  that  the  advantage  of  reduced  segment  copying  in 
PSUNIX  is  offset  by  the  increased  complexity  of  the  memory 
management  routines. 
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REAL 
USER 
SYS 


UNIX 
3:32.0 
1:30.3 
29.7 


PSUNIX 

3:29.0 

1 :29.8 

31.2 


Table  1 


BENCHl,  32K  Words 


REAL 
USER 
SYS 


UNIX 
a:  17.0 
1  :32.5 
30.6 


PSUNIX 

a:20.o 

1:31.6 

33.0 


Table  2.   BENCH2,  32K  Words 


REAL 
USER 
SYS 


UNIX 
3:50.7 
1:31.7 
31.5 


PSUNIX 

3:49.0 

1:31.8 

32.1 


Table  3.   BENCH2,  40K  Words 


REAL 
USER 
SYS 


UNIX 
3:49.0 
1:32.0 
32.1 


PSUNIX 

3:38.0 

1  :30.8 

33.0 


Table  4.   BENCH2,  48K  Words 


REAL 
USER 
SYS 


UNIX 
3:38.0 
1:31.3 
31.9 


PSUNIX 

3:34.0 

1:31.3 

32.8 


Table  5.   8ENCH2,  56K  Words 


REAL 
USER 
SYS 


UNIX 
3:32.0 
1  :30.5 
30.1 


PSUNIX 

3:29.0 

1:30.8 

32.2 


Table  6.   BENCH2,  64K  words 
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VII.   CONCLUSIONS  AND  RECOMMENDATIONS 


The  most  interesting  result  of  this  thesis  is  that  it 
confirms  the  axiom  that  a  simple  program  is  very  often  a 
good  program.  From  the  standpoint  of  performance  alone;  the 
simpler  UNIX  memory  manager  is  as  efficient  as  PSUMIX. 
PSUNlX  is  attractive  because  it  provides  an  additional 
feature^  segmentation/  with  no  performance  penalty. 
Although  PSUNIX  could  be  placed  into  production  use  at  once/ 
it  would  prooably  be  a  better  idea  to  proceed  with  the 
develooment  of  SUNIX.  From  the  data  oresented  on  segment 
sizes*  it  appears  that  SUNIX  will  perform  at  least  as  well 
as  PSUMIX.  SUNIX  memory  management  routines  will  have  the 
advantages  of  being  both  smaller  and  simpler.  Because  of 
this/  they  will  reguire  less  storage/  be  easier  to  maintain, 
and  cause  less  memory  management  overhead. 

No  matter  which  version  is  implemented/  many  parts  of 
the  memory  manager  will  remain  potential  candidates  for 
improvement.  The  basic  memory  allocation  primitive/ 
"malloc/"  is  an  example.  In  rein  lb],  Knuth  suggests  many 
oossible  imDrovements  to  the  simple  algorithm  used  in 
"malloc."  Although  Knuth'  s  logic  is  compelling,  we  may  again 
be  surprised  by  the  correlation  between  simplicity  and 
goodness . 
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A  more  important  project  will  be  the  development  of  the 
system  calls  that  will  be  used  to  olace  a  process's  data 
segment  in  specific  areas  of  memory.  Successful  completion 
of  this  project  will  be  required  before  the  full  benefits  of 
segmentation  will  be  attained. 
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APPENDIX  A:  MEMORY  MANAGEMENT  CONTROL  BLOCKS 


A.   DOCUMENTATION  FORMAT 

This  aDpendi  x  contains  documentation  of  the  control 
blocks  in  the  UNIX,  SUNIX,  and  PSUNIX  versions  of  the 
©Derating  system  that  are  direcly  or  indirectly  concerned 
with  memory  management.  The  source  code  for  these  control 
blocks  is  found  in  files  in  the  directory  /usr/sys.  Each 
control  block  is  documented  under  an  u  o  p  e  r  case  roman 
letter.  The  name  of  the  source  code  file  containing  the 
control  block  is  noted  following  the  control  block  name. 
The  documentation  of  each  control  block  is  divided  into  two 
subsections:  overview  and  significant  data  elements.  Only 
the  data  elements  significant  to  memory  management  are 
documented.  Because  this  aooendix  was  designed  to  be  used 
with  a  copy  of  the  system  code,  the  data  elements  are 
documented  in  the  order  in  which  they  apoear  in  the  source. 

In  accordance  with  the  non-disclosure  terms  of  t^e 
software  agreement  with  Western  Electric,  program  listings 
are  not  orovided  as  oart  of  this  thesis.  Authorized  users 
of  the  UNIX  ooerating  system  may  obtain  machine-readable 
copies  of  programs  oroduced  for  this  thesis  by  contacting 
the  Naval  Postoraduate  School. 
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B.   COREMAP,  systm.h 

I  .   Overview 

COREMAP  is  an  array  of  structures  that  keeps  track 
of  the  unallocated  areas  of  main  storage.  Each  structure 
contains  the  startinq  physical  block  number  and  the  size  of 
an  unallocated  storage  area .  COREMAP  is  sorted  so  that  its 
entries  are  in  physical  block  number  seauence.  See  the 
documentation  of  "malloc.c"  in  APPENDIX  B  for  descriotions 
of  the  memory  management  primitives  that  manipulate  COREMAP. 

2,       Significant  Data  Elements 

a  .   char  *m«-s  i  ze 


This  is  the  size  of  the  free       area       in   64-byte 


b 1 oc  ks  . 


b .   char  *m«-addr 

This  is  the  memory  physical  block  number  of  the 
start  of  the  free  area.  If  this  field  is  zero*  it  marks  the 
end  of  COREMAP. 

C.   SwAPMAP,  systm.h 

1  .   Overv  i  ew 

SimAPMAP  is  an  array  of  structures  that  keeos  track 
of  the  unallocated  areas  on  the  swap  device.  Each  structure 
contains  the  startinq  physical  sector  number  and  the  size  of 
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an  unallocated  area.  S  V>i  A  P  M  A  P  is  sorted  so  that  its  entries 
are  in  physical  sector  number  sequence.  The  same  primitives 
used  to  maipulate  COREMAP  are  used  for  SwAPMAP.  See 
APPENDIX  B. 

2.   Significant  Data  Elements 

a  .   char  *m«-s  i  ze 

This  is  the  size  of  the  free  area  in  256-word 
sectors . 

b .   char  *m«-addr 

This  is  the  memory  physical  sector  number  of  the 
start  of  the  free  area.  If  this  field  is  zeror  it  marks  the 
end  of  SWAPMAP. 

D.   PROC,  Droc.h 

1.   Overview 

The  array  "proc"  is  an  array  of  structures  referred 
to  as  PROCs  in  this  thesis.  One  of  these  structures  is 
allocated  to  each  active  process  in  the  system  for  the  life 
of  the  process.  The  array  is  located  in  the  Kernel  address 
space  ana  is  oermanently  resident  in  main  memory.  A 
orocess's  PROC  contains  all  Drocess  information  that  cannot 
be  swapped  out  of  main  memory. 
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2.   Significant  Data  Elements 

a  .   char  o<-  f  1  ag 

This  is  a  word  of  flags.  Bit  0  of  this  word  is 
the  SLOAD  flag.  If  it  is  set/  the  process  is  in  main  memory. 
Bit  2  of  this  word  is  the  SLOCK  flag.  If  it  is  set/  the 
process  is  locked  in  memory  and  may  not  be  swaoped  out.  Bit 
4  of  this  word  is  the  SSWAP  flag;  if  it  is  set;  the  process 
is  being  swapped  out.  In  PSUNIX,  bit  15  of  this  word  is  the 
CONT  flag.  If  the  bit  is  set/  it  means  that  both  the 
process's  data  and  the  process's  stack  must  be  contiguous  in 
ma  i  n  memo  ry . 

b  .   i  nt  p*-addr 

This  field  is  present  only  in  UNIX.  If  the 
process  is  resident  in  main  memory/  it  is  the  physical  block 
number  of  the  orocess's  UVECTOR.  If  the  process  is  swaoped 
out/  it  is  the  swap  device  block  number  of  the  swapped 
i  mage . 

c  .   i  nt  p«-s  i  ze 

This  field  is  present  only  in  UNIX.  It  is  the 
size  of  the  orocess's  swaooable  image  measured  in  64-byte 
blocks. 

d.   i  nt  *p«-t  ex  t  p 

This  is  a  pointer  to  the  process's  TEXT.  If  the 
value  is  zero/  the  orocess  does  not  have  shared  text. 
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e  .   i  n  t  p<-cadar 

This  fiela  is  oresent  only  in  SUNIX  and  PSUNIX. 
It  is  the  main  memory  physical  block  number  of  the  orocess's 
UVECTOR  if  the  process  is  in  memory. 

f  .   i  nt  o«-oaddr  [8] 

This  ar ray  is  present  only  in  PSUNIX.  The 
integers  in  the  array  are  the  memory  physical  block  numbers 
of  the  orocess's  pages.  The  order  of  pages  is:  first  data 
pages  from  low  to  high  virtual  address  and  then  stack  pages 
from  high  to  low  virtual  address. 

g  .   i  n  t  o«-dadd  r 

This  field  is  present  only  in  SUNIX  and  PSUNIX. 
It  is  the  swap  device  block  number  of  the  process's  swap 
space.   If  it  is  zero/  the  process  has  no  swap  space. 

h  .   i  nt  p«-ds  i  ze 

This  field  is  present  only  in  SUNIX  and  PSUNIX. 
It  is  the  size  of  the  orocess's  data  in  64-byte  blocks. 

i  .   i  nt  o<-ss  i  ze 

This  field  is  present  only  in  SUNIX  and  PSUNIX. 
It  is  the  size  of  the  process's  stack  in  64-byte  blocks. 
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E.   TEXT,  text.h 

1.  Overview 

The  array  "text"  is  an  array  of  structures  called 
TEXTs  in  this  thesis.  Each  segment  of  sharable  code  is 
assigned  a  TEXT  for  the  life  of  the  segment.  The  text 
contains  all  data  on  the  usage  and  status  of  the  segment. 
The  "text"  ar ray  is  found  in  the  Kernel  address  space  and  is 
permanently  resident  in  main  memory. 

2.  Significant  Data  Elements 

a  .   i  nt  x«-dadd  r 

This  is  the  swap  device  block  number  of  the  text 
segment's  image. 

b.  int  x«-caddr,  int  xcaddr  [8] 

In  UNIX  and  SUNIX,  this  is  the  memory  physical 
block  number  of  the  start  of  the  text  segment.  In  PSUNIX 
this  array  contains  the  memory  physical  block  numbers  of  the 
pages  of  the  text  segment. 

c.  int  x*-size 


This  is  the  size  of  the  text  segment  in   64-byte 


b 1 oc  ks  . 
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d  .   char  x«-coun  t 

This  is  the  number  of  processes  sharing  the  text 
segment . 

e .   char  x«-ccount 

This  is  the  number  of  memory  resident  processes 
using  the  text  segment. 

F.   UVECTOR,  user.h 

1 .  Overview 

The  structure  "user"  is  referred  to  as  the  UVECTOP 
in  this  thesis.  One  of  these  structures  is  part  of  the 
swappable  image  of  each  orocess.  The  UVECTOR  contains  all 
process  data  that  is  not  needed  when  the  process  is  not  in 
control  of  the  processor.  When  the  process  is  in  control  of 
the  processor,  the  orocess's  UVECTOR  resides  at  virtual 
Kernel  aata  space  address  140000  octal.  The  portion  of  the 
UVECTOR  not  used  by  Drocess  data  elements  is  used  as  the 
Kernel  mode  processor  stack. 

2.  Significant  Data  Elements 

a  .   i  n  t  u«-u  i  sa  C 1  6] 

In  UNIX  this  array  contains  the  64-byte  block 
displacements  from  the  start  of  the  region  of  the  process's 
data  and  stack  pages.  In  SUN IX  and  PSUNIX  this  array  is  not 
used  . 
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b  .   int  u«-u  i  sd  [  1  6] 

This  array  contains  the  prototypes  of  the 
process's  user  I-SDace  and  0-soace  paae  descriptor 
reg  i  sters. 

c.   int  u«-t  s  i  ze 

This  is  the  size  of  the  process's  shared  text 
segment . 

d  .   int  u<-ds  i  ze 

This  is  the  size  of  the  process's  data. 
e.   int  u  *-  s  s  i  z  e 

This  is  the  size  of  the  process's  stack. 

G .   PAGET ,  oage . h 

1 .   Overview 

An  array  of  "paget"  structures  is  referred  to  as  a 
PAGET  in  this  thesis.  This  is  a  page  table  containing  the 
sizes  and  addresses  of  the  process's  pages.  A  PAGET  is 
always  organized  so  that  data  pages  apDear  first  from  low  to 
high  virtual  address  followed  by  stack  pages  from  high  to 
low  virtual  address. 
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2.   Significant  Data  Elements 

a  .   i  n  t  t  «-oaddr 

This  is  the  memory  physical  block  number  of   the 
start  of  the  page . 

b  .   i  n  t  t  <-os  i  ze 

This  is  the  size  of  the  Daae  in  64-byte  blocks. 
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APPENDIX  B:  MEMORY  MANAGEMENT  ROUTINES 


A.   DOCUMENTATION  FORMAT 

This  aopendix  contains  documentation  of  functions  within 
the  UNIX,  SUNIX,  and  PSUNIX  versions  of  the  operating  system 
that  are  directly  or  indirectly  concerned  with  memory 
management.  Because  this  aopendix  is  designed  to  be  used 
with  a  copy  of  the  source  code,  the  documentation  is  divided 
into  sections  that  correspond  to  the  divisions  of  the  source 
code.  The  UNIX  source  is  divided  into  several  blocks  of 
code  containing  related  functions.  These  blocks  of  code  are 
stored  as  files  in  two  directories:  /usr/sys/dmr  for  device 
management  functions  and  /usr/sys/ken  for  the  remainder  of 
the  system.  The  documented  functions  in  each  block  of  code 
are  grouped  under  an  upper  case  roman  letter.  Each  function 
within  each  block  is  listed  under  an  arabic  numoer.  The 
functions  are  documented  in  the  same  order  in  which  they  are 
found  in  the  code  blocks  with  any  new  functions  appearing 
last.  The  documentation  of  each  function  is  divided  into 
the  following  subsections:  parameters,  functional 
description,  returned  values,  and  error  conditions.  Any 
differences  in  function  documentation  among  the  three 
versions  of  the  operating  system  are  noted  in  the 
aopropriate  subsection. 
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B .   main.c 

1 .   sureg (  ) 

a .  Paramet  ers 

The  current  process's  UVECTOR  and  PROC  are 
implied  parameters. 

b.  Functional  Description 

This  function  loads  the  User  descriptor  and 
address  registers  in  the  memory  management  unit.  The 
descriptor  registers  are  obtained  from  the  array  u«-uisdt]  in 
the  current  UVECTOR.  Address  register  loading  is  controlled 
by  the  values  of  u<-tsize»  u*-dsizer  u«-ssize/  and  u«-sep  in 
the  current  UVECTOR.  In  UNIX  the  page  address  registers  are 
determined  based  on:  the  region  address?  p«-addr,  in  the 
current  PROC;  the  text  segment  address,  x^caddr,  in  the 
current  TEXT;  and  the  page  di sol acement s  in  the  array 
u«-uisaC]  in  the  current  UVECTOR.  The  page  displacements  are 
not  used  in  SUNIX  or  UNIX.  In  SUNIX  the  segment  adaresses, 
p*-daddr  and  p*-saddr,  are  used  instead  of  o«-addr.  In  PSUNIX 
the  page  addresses  in  the  array  p«-paddrU  in  the  PROC  and 
x«-caddrU  in  the  TEXT  are    used. 

c.  Returned  Values 

The  values  returned  by  this  function  are  not 
chec  ked. 
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d.   Error  Conditions 

This  function  has  no  error  conditions. 

2.       estabur(nt/nd/ns»sep) 

a .  Pa rame t ers 

The  first  three  parameters  are  the  sizes  of  the 
current  process's  data  and  stack  in  64-byte  blocks.  The 
value  of  "seD"  is  a  flag  that  is  set  if  the  process  has 
split  instruction  and  data  space.  The  current  Drocess's 
UVECTOR  is  an     implied  input. 

b.  Functional  Description 

This  function  first  checks  the  validity  of  its 
arguments.  It  loads  the  prototypes  of  the  memory  management 
page  descriptor  registers  into  the  array  u<-uisdU  in  the 
current  UVECTOR.  In  UNIX  it  also  loads  page  start 
displacements  in  blocks  measured  from  the  beginning  of  the 
region  or  text  into  the  array  u «-  u  i  s  a  U  in  the  current 
UVECTOR.  In  both  SUNIX  and  PSUMX,  u«-uisaU  is  not  loaded; 
the  values  of  the  Darameters  are  placed  in  the  variables 
u«-tsize*  u<-dsize*  u*-ssize»  and  u<-sep  in  the  current  UVECTOR. 
In  all  versions*  "suregO"  is  called  to  load  the  actual 
memory  management  registers. 

c.  Returned  Values 

If  the  parameters  are  invalid*  minus  one  is 
returned?  otherwise*  zero     is  returned. 
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d .   Error  conditions 


The  minus  one  return  indicates  an  error   to   the 


ca 1 ler. 

3  .   nseg ( n ) 

a .  Paramet  ers 

The  parameter  is  a  number  of  memory  blocks. 

b.  Functional  Description 

This  function  calculates  the  number  of  pages, 
rounded  uo«  in  the  number  of  blocks  specified  in  the 
paramet  er . 

c  .   Returned  Va 1 ues 

The  returned  value  is  the  number  calculated. 
d.   Error  Conditions 

This  function  has  no  error  conditions. 
4.   cksizeCnt/nd/nS/Sep) 

a .  Paramet  ers 

See  westabur(nt,nd/ns,sep)." 

b.  Functional  Description 

This  function  is  present  only  in  SUNIX  and 
PSUNIX.   It  checks  its  parameters  to  see  if  they  are    valid. 
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c .  Ret  urned  Values 

This   function   returns    minus    one    if    the 
parameters  are    invalid  and  zero  if  thev  are  valid. 

d.  Error  Conditions 


A  minus  one  return  indicates   an   error   to   the 


ca  1  1  er  . 


C .   ma  1  1 oc  .c 

1 .   ma  1  1 oc (mo  t s  i  ze  ) 

a .  Pa  ramet  ers 

The  parameters  are  a  pointer  to  a  map  array  and 
a  size  specified  in  blocks  to  be  allocated  from  the  map. 

b.  Functional  Description 

This  function  allocates  space  in  main  memory  and 
on  the  swao  device.  If  memory  is  to  be  allocated/  the  first 
parameter  must  point  to  COREMAP.  If  swap  soace  is  to  be 
allocated/  it  must  point  to  SWAPMAP.  The  amount  of  space 
needed  must  be  specified  in  64-byte  blocks  if  memory  is  to 
be  allocated  and  in  256-word  sectors  if  swao  space  is  to  be 
a  1  located. 

c.  Returned  Values 

This  function  returns  the  physical  block  number 
of   the   space   if   allocation   is   successful   and   zero  if 
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allocation  is  unsuccessful. 

d.   Error  Conditions 

A  return  value  of  zero  indicates  allocation 
failure  to  the  caller. 

2 .   mfree(mp,si ze,aa) 

a.  Parameters  * 

The  first  two  parameters  are  the  same  as  those 
of  "malloc".  The  third  oarameter  is  a  physical  block  number 
of  an  area    of  main  storage  or  swap  space. 

b.  Functional  Description 

This  function  frees  the  specified  area  of  main 
storage  or  swap  space.  If  memory  is  to  be  freed,  the  first 
parameter  must  point  to  C  0  R  E  M  A  P  .  If  swap  space  is  to  be 
freed,  it  must  point  to  SwAPMAP.  The  size  must  be  specified 
in  64-byte  blocks  if  memory  is  to  be  freed  and  in  256-word 
sectors  if  swap  space  is  to  be  freed. 

c  .   Ret  urned  Val ues 


The  value   returned   by   this   function   is   not 


checked. 


d.   Error  Conaitions 


This  function  has  no  error  conditions 
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D .   si  g.c  ^ 

1  .   core (  ) 

a  .   Pa  rame t ers 

The  current  process's  UVECTOR,  PROC ,  TEXT  and 
address  space  are  implied  parameters. 

b.  Functional  Description 

This  function  creates  a  memory  image  file 
consisting  of  the  current  orocess's  UVECTOR,  data,  and 
stack.  In  UNIX  this  function  uses  "estabur"  to  redefine  the 
process's  virtual  address  space  to  make  the  data  and  stack 
contiguous.  It  then  writes  the  data  and  stack  in  one  output 
operation.  In  SUNIX  and  PSUNIX  this  is  impossible  because 
the  data  and  stack  may  not  be  physically  contiguous.  Two 
output  operations  are  used,  one  output  oDeration  for  the 
data  ana  one  for  the  stack.  If  an  output  error  occurs  an 
indication  is  left  in  u*-error  in  the  current  UVECTOR. 

c.  Returned  Values 

This  function  returns  zero  if  it  is  successful 
and  one  if  an  output  error  occurs. 

d.  Error  Conditions 

The  one  return  indicates  an  error  to  the  caller. 
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2 .   grow ( so ) 

a  .   Paramet  ers 

The  parameter  is  the  value  of  the  current 
process's  User  stack  pointer.  The  current  process's  UVECTOR 
and  PROC  are  implied  parameters. 

b.   Functional  Description 

This  function  is  called  asynchronously  when  the 
current  process's  stack  attempts  to  exDand  beyond  the  size 
allocated  to  it.  This  function  calculates  the  number  of 
blocks  that  the  stack  must  be  increased?  validates  the  new 
stack  size?  and  acquires  the  memory  that  is  needed.  In  UNIX 
"expand"  is  called  to  establish  the  new,  larger  address 
space.  In  P  S  U  N I  X  "sexpand"  is  called  to  establish  the  new/ 
larger  stack.  In  SUNIX  this  function  attempts  to  acauire 
space  for  the  new  stack.  If  it  is  unsuccessful/  it  calls 
"ceswao"  to  acquire  the  space.  If  it  is  successful/  it 
copies  the  old  stack  to  the  new  and  frees  the  old  memory. 
In  all  versions  the  newly  acauired  space  is  cleared  and 
"estabur"  is  called  to  reload  the  memory  management 
regi  st ers . 

c  .   Ret u  rned  Values 


This   functon   returns    a    zero 
unsuccessful  and  a  one  if  it  is  successful. 


if    it 


1  s 
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d .   Error  Conditions 


A  zero  return  indicates  an  error  to  the  call 


e  p 


E  .   s 1 o  .c 


1  .   sched( ) 


a  •   Paramet  ers 


The  PROCs  and  TEXTs  of  all  processes  are    implied 


Da  ramet  ers. 


b.   Functional  Description 

This  function  searches  for  swapped  out  processes 
that  "deserve"  to  be  returned  to  memory.  It  selects  the 
most  "deserving"  process;  acquires  soace  for  it  by  swapping 
out  other  processes*  if  necessary;  and  returns  it  to  main 
memory.  In  SUM  IX  and  PSUNIX  two  new  functions  are  used: 
"pralloc"  to  acquire  main  memory  for  the  process  and 
"prswap"  to  swap  it  in. 

c  .   Returned  Va 1 ues 

This  function  does  not  return.  It  is  the  basic 
instruction  1 ooo  of  Process  0.  It  goes  to  sleeo  and  is 
reawakened  about  once  oer  second  by  the  clock  function. 

d.   Error  Conditions 

In  UNIX,  if  a  swap  input  or  output  error  occurs, 
the  message  "swap  error"  will  be  sent  to  the  console  and  the 
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system  will  crash. 

2 .   newproc ( n rp ) 

a .  Paramet  ers 

The  parameter  is  a  pointer  to  a  PROC  to  be 
established  for  a  child  process.  The  current  process's 
UVECTOR,  PROC/  and  TEXT  are  implied  parameters. 

b.  Functional  Description 

This  function  creates  an  exact  duplicate  of  the 
current  process  as  a  child  of  the  current  process.  It  first 
makes  the  appropriate  entries  in  the  child  and  parent  PROCs 
and  in  the  TEXT  if  one  exists.  It  then  attempts  to  acquire 
memory  for  the  child.  If  it  is  successful/  it  simply  copies 
the  parent's  image  to  the  new  memory.  If  it  fails?  it  swaps 
out  a  copy  of  the  parent's  i maqe  to  be  returned  to  memory  as 
the  child.  In  SUNIX  and  PSUNIX,  a  new  function,  "pralloc," 
is  used  in  the  attempt  to  acauire  memory  for  the  child.  In 
PSUNIX  a  new  function  "prcooy"  is  used  to  cooy  the  Parent's 
i  mage . 

c.  Returned  Values 

This  function  returns  zero  to  the  parent 
process.  The  return  to  the  child  does  not  come  from  this 
function  but  from  the  scheduling  function  "swtch".  The 
child  can  identify  itself  as  the  child  because  "swtch" 
returns  a  one  to  it.   This  is  one  of  the  most  important   and 
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subtle  phenomena  in  UNIX. 

d.   Error  Conditions 

If  the  PROC  pointed   to   by   the   parameter   is 

already   allocated   to  an   active   orocess,  the  message  "no 

procs"  will  be  sent  to  the   console   and   the   system   will 
c  rash  . 

3.   expand ( news i ze ) f  expand(newd,  news) 

a  •   Paramet  ers 

In  UNIX  this  function  is  called  with  a  single 
parameter/  the  new  region  size.  In  SUN  IX  and  PSUNIX  this 
function  is  called  with  two  parameters:  the  new  data  size 
and  the  new  stack  size.  The  current  process's  PROC  and 
UVECTQR  are  imolied  parameters. 

b.   Functional  Description 

In  UNIX  this  function  is  called  whenever  the 
size  of  the  current  orocess's  address  space  changes.  It  cuts 
the  new  size  in  o«-size  in  the  current  PROC.  If  the  new  size 
is  smaller,  it  frees  the  unwanted  storage.  If  the  new  size 
is  larger,  it  attempts  to  acguire  a  new  region  for  the 
process.  If  it  succeeds,  it  copies  the  process's  image  to 
the  new  region.  If  it  fails,  it  causes  the  process  to  be 
swapped  out  with  the  new  size  noted  in  its  PROC.  When  the 
process  returns  to  memory,  it  will  return  at  the  new  size. 
If   the   process  is  swapped  out,  this  function  calls  "swtch" 
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to  change  current  processes.  In  SUNIX  and  PSUNIX,  this 
function  is  called  only  to  acquire  an  address  soace  for  a 
process  that  currently  has  only  a  UVECTOR.  In  these  systems 
it  Duts  the  two  new  sizes  in  o «-  d  s  i  z  e  and  p  *-  s  s  i  z  e  in  the 
current  PROC.  In  UNIX  the  function  "xswap"  is  called  to 
swap  out  the  process;  in  SUNIX  and  PSUNIX  "ceswap"  is  used. 
In  UNIX,  "sureg"  is  called  to  load  memory  management 
registers;  in  SUNIX  and  PSUNIX,  this  is  not  necessary. 

c.  Returned  Values 

The  return  codes  of  this  function  are  not 
checked.  The  caller  has  no  way  of  determining  if  the  process 
was  increased  in  size  directly  or  by  swapping.  In  UNIX,  if 
the  process  is  swappea,  this  function  does  not  return  to  its 
caller.  The  return  comes  from  a  subsequent  call  to  "swtch" 
after  the  process  has  returned  to  memory. 

d.  Error  Conai  t  ions 

This  function  has  no  error  conditions. 
Q .   ceswap (ods , oss ) 


a.   Paramet  ers 

The  parameters  are    the   current   process's   data 
and  stack  sizes  in  64-byte  blocks. 
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b.   Functional  Description 

This  function  is  present  only  in  SUNIX  and 
PSUNIX.  It  is  called  to  do  the  housekeeping  that  is 
necessary  for  expansion  swapping.  It  calls  "xswao"  to 
perform  the  actual  swapping  and  then  it  calls  "swtch"  to 
place  a  new  process  in  control  of  the  processor. 

c  .   Ret  u  rned  Va 1 ues 

This  function  does  not  return  to  its  caller. 
The  return  to  the  caller  comes  from  a  subseauent  call  to 
"swtch"  after  the  process  has  returned  to  memory. 

d.   Error  Conditions 

This  function  has  no  error  conditions. 

5  .   swf  ree ( rp) 

a .  Paramet  ers 

The  parameter  is  a  pointer  to  a  PROC. 

b.  Functional  Description 

This  function  frees  any  swap  space  belonging  to 
the  process  indicated  by  the  parameter,  and  it  zeroes  out 
p+-daddr,  the  pointer  to  the  soace  in  the  PROC. 

c.  Returned  Values 


The  values  returned  by   this   function  are       not 


checked. 
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d .   Error  Conditions 

This  function  has  no  error  conditions. 
6 .   sexoand ( news ) 

a .  Pa  ramet ers 

The  parameter  is  the  new»  larger  stack  size. 

b.  Functional  Descriotion 

This  function  is  present  only  in  PSUNIX.  It  is 
called  from  "grow"  to  increase  the  stack  size.  See  the 
description  of  "exoand". 

c.  Returned  Values 
See  "expand" . 

d.  Error  Conditions 
See  "expand". 

7  .   dexpand ( newd ) 

a .  Paramet  ers 

The  oarameter  is  the  new/  larger  data  size. 

b.  Functional  Descriotion 

This  function  is  present  only  in  PSUNIX.  It  is 
called  from  "sbreak"  to  increase  the  data  size.  See  the 
descriotion  of  "expand". 
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c  .   Ret  umed  Va  1  ues 

See  "expand". 
d.   Error  Conditions 

See  "exDand" . 
8  ♦   cont  i  g ( ro) 

a .  Pa  rame t e  rs 

The  parameter  is  a  pointer  to  the  current 
process ' s  PROC . 

b.  Functional  Description 

This  function  is  present  only  in  PSUNIX.  It  is 
called  from  "physio"  to  make  both  the  stack  and  the  data  of 
the  current  process  physically  contiguous  in  main  storage. 
It  indicates  that  the  orocess  requires  contiguous  segments 
by  setting  the  CONT  bit  in  the  p  <-  f  1  a  g  in  the  process's  PROC; 
then  it  attempts  to  acquire  physically  contiguous  main 
storage  with  "oalloc".  If  it  succeeds,  it  cooies  the  old 
noncontiguous  cages  to  the  new  contiguous  ones.  If  it 
fails*  it  calls  "ceswap"  to  swao  out  the  process.  When  it 
returns  to  main  memory*  the  CONT  flag  will  cause  its  storage 
to  be  allocated  contiguously. 

c.  Returned  Values 


The  values  returned  by   this   function  are       not 


chec  ked . 
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d.   Error  Conditions 


This  function  has  no  error  conditions 


F .   sys  1  .c 

1  .   exec ( ) 

a  .   Parame t ers 

The  current  process's  UVECTOR,  PROC,  and  TEXT 
are  implied  parameters.  Because  this  function  is  a  system 
calif  the  array  u«-arg[]  in  the  UVECTOR  contains  additional 
arguments.  See  Ref.  till  . 

b.   Functional  Description 

This  system  call  is  used  by  the  current  process 
to  invoke  a  new  program.  It  copies  any  program  arguments  to 
a  buffer,  unlinks  from  the  old  TEXT,  frees  its  old  main 
storage,  establishes  a  new  TEXT  if  the  new  program  has 
shared  code,  acqui  res  storage  for  the  new  data  and  stack, 
clears  the  region  acquired,  reads  in  the  new  data,  copies 
the  arguments  to  the  new  stack,  and  changes  the  memory 
management  registers  to  make  them  compatible  with  the  new 
address  space.  In  UNIX  "expand"  is  used  to  free  the  old 
main  storage;  in  SUNIX  and  PSUNIX  a  new  function,  "prfree" , 
is  used.  In  UNIX  "estabur"  is  used  to  validate  the  storage 
requirements  of  the  new  program;  in  SUNIX  and  PSUNIX 
"cksize"  is  used. 
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c  .   Ret  umed  Values 

This  system  call  returns  to  the  caller  only  if 
it  encounters  an  error.  If  no  error  has  occurred*  it 
returns  to  the  first  instruction  of  the  new  program. 

d.   Error  Conditions 

This  function  returns  to  the  caller  if  the 
storage  requirements  of  the  new  orogram  are  invalid. 

2.   exi  t  ( ) 

a .  Pa  ramet  ers 

The  current  process's  UVECTOR,  PROC,  and  TEXT 
are  implied  parameters. 

b.  Functional  Description 

This  function  is  the  system  call  used  to 
terminate  the  current  orocess.  It  clears  signals/  closes 
any  ooen  files*  unlinks  from  the  current  TEXT,  acquires  a 
block  on  the  swao  device/  copies  the  first  25b  bytes  of  the 
current  UVECTOR  to  the  block/  and  frees  main  storaae.  In 
SUNIX  and  PSUNIX/  old  main  storage  is  freed  by  Mprfree/"  a 
new  function.  Because  of  the  different  method  of 
controlling  swap  space/  SUNIX  and  PSUNIX  use  "swfree"  to 
free  any  swao  space  allocated  to  the  process. 
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c .  Returned  Va 1 ues 

This  system  call  does  not  return  to  its  caller. 
The  next  function  invoked  for  this  process  is  "wait"  which 
completes  the  cleanup. 

d.  Error  conditions 

This  system  call  has  no  error  conditions. 
3  .   sbreak ( ) 

a .  Pa  rame t  ers 

The  current  process's  UVECTOR  and  PROC  are 
implied  parameters.  Because  this  function  is  a  system  call/ 
an  additional  argument/  the  virtual  address  of  the  new  end 
of  the  data/  is  found  in  the  array  u «-  a  r  g  [  ]  in  the  UVECTOR. 

b.  Functional  Description 

This  function  is  the  system  call  used  to  change 
the  size  of  the  current  process's  data  area.  It  calculates 
the  new  data  size  desired  by  the  current  process  and 
validity  checks  the  current  process's  total  storage 
reguirement.  If  the  requirement  is  not  valid  it  returns 
without  fulfilling  the  recju  i  remen  t  .  In  UNIX/  "expand"  is 
used  to  establish  the  new  region.  In  PSUNIX/  "dexpand"  is 
used  to  change  the  size  of  the  data.  In  SUNIX/  this 
function  attemDts  to  do  the  work  itself.  It  puts  the  new 
size  in  p*-dsize  in  the  current  PROC.  If  the  new  size  is 
smaller/  it  frees  the  excess  storage.   If  the   new   size   is 
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larger,  it  attempts  to  acauire  it.  If  it  fails,  it  calls 
"ceswap"  to  acauire  the  space  by  swapping.  In  all  systems 
the  newly  acguired  soace  is  cleared. 

c .  Ret  urned  Values 

Values  returned  by   this   system   call  are       not 
checked . 

d.  Error  Conoi  t  ions 


If  the  new  storage  reguirement  is  not  valid, 
this  system  call  returns  without  allocating  the  storage. 
This  will  usually  cause  the  process  to  terminate  abnormally 
because  of  a  memory  management  error. 

G.   text  »c 

1.   xswao (p, f f , os  )  ,  xswap (p , f f , ods ,oss  ) 

a .   Parameters 

In  UNIX  this  function  is  called  with  three 
parameters.  In  SUNIX  and  PSUNIX,  it  is  called  with  four 
parameters.  The  first  parameter  is  a  pointer  to  the  PROC  of 
a  process  to  be  swapped  out  of  main  memory.  The  second 
parameter  is  the  memory  free  flag.  In  UNIX  the  third 
parameter  is  the  process's  region  size  in  6^-byte  blocks. 
In  SUNIX  and  PSUNIX  the  third  and  fourth  parameters  are  the 
process's  data  and  stack  sizes  in  64-byte  blocks. 
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b.   Functional  Description 

In  UNIX  this  function  allocates  swao  SDace  for 
the  process  and  swaps  it  out.  In  SUNIX  and  PSUNIX  this 
function  allocates  swao  space  onlv  for  those  processes  that 
do  not  already  have  it.  In  all  versions  of  the  operating 
system*  memory  is  freed  if  the  memory  free  flag  is  set. 
This  flag  will  not  be  set  if  this  function  has  been  called 
by  "newproc"  to  create  a  copy  of  a  parent  process. 

c  •   Ret  urned  Va 1 ues 

The  value  returned  by  this  function  is  not 
chec  ked. 

d.   Error  Conditions 

If  swao  space  must  be  allocated  but  none  is 
available/  the  message  "out  of  swap  space"  will  be  sent  to 
the  console  and  the  system  will  crash.  If  an  output  error 
occurs  during  the  swao,  the  message  "swap  error"  will  be 
sent  to  the  console  and  the  system  will  crash. 

2 .   x  f  ree (  ) 

a .   Paramet  ers 

The  current  process's  UVECTOR  and  TEXT  are 
implied  oarameters. 


76 


b.  Functional  Description 

This  function  relinquishes  use  of  the  current 
process's  shared  text.  If  the  current  Drocess  has  no  shared 
text/  this  function  just  returns.  If  the  current  process 
has  shared  text/  "xccdec"  is  called  to  decrement  the  TEXT's 
in-memory  use  count.  The  TEXT's  active-process  use  count  is 
then  decremented.  If  this  count  has  reached  zero  and  if  the 
text  segment  is  not  to  be  retained/  the  TEXT's  swap  space 
and  the  TEXT  itself  are    freed. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
chec  ked . 

d.  Error  Conditions 

This  function  has  no  error  conditions. 
3  .   xal  1 oc ( i  p) 

a .  Paramet  ers 

The  parameter  is  a  pointer  to  the  i node  of  the 
text  segment  that  is  to  be  established  or  located.  The 
current  orocess's  UVECTOR  and  PROC  and  all  TEXTs  are  implied 
parameters . 

b.  Functional  Description 

This  function  establishes  the  shared  text 
segment   requested   by   the  current  process.   If  the  current 
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process  does  not  require  shared  text/  this  function  returns. 
If  the  process  does  require  shared  text/  this  function 
searches  the  array  of  TEXTs  for  a  previously  established 
TEXT  for  the  requested  segment.  If  one  is  found  its 
active-process  use  count  is  incremented.  If  the  requested 
segment  is  in  main  memory/  the  TEXT'S  in-memory  use  count  is 
also  incremented  and  the  function  returns.  If  a  TEXT  has 
not  been  previously  established/  an  unallocated  TEXT  is 
located  and  allocated  to  the  text  segment.  Swap  space  is 
allocated  for  the  text  segment.  The  current  process's 
address  space  is  increased  using  "expand"  to  get  soace  into 
which  the  text  segment  can  be  read.  The  text  segment  is 
read  into  memory  and  then  it  is  written  out  to  the  swap 
space  acquired  for  it.  The  memory  acquired  for  the  text 
read  is  freed  using  "expand"  in  UNIX  and  "prfree"  in  SUNIX 
and  PSUNIX.  The  address  of  the  TEXT  is  placed  in  D*-textp  in 
the  current  PROC.  The  current  process  is  swapped  out  with 
"xswap".  When  it  returns  to  memory/  the  text  segment  will 
return  with  it. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
checked . 

d.  Error  Conditions 

If  a  TEXT  must  be  allocated  and  one  is  not 
availaole/  the  message  "out  of  text"  will  be  sent  to  the 
console  and  the  system  will  crash.   If  swao   soace   must   be 
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allocated  and  none  is  available/  the  message  "out  of  swap 
space"  will  be  sent  to  the  console  and  the  system  will 
c  rash  . 

4 .   xccdec (xo) 

a .  Paramet  ers 

The  parameter  is  a  pointer  to  a  PROC.  The  PROC ' s  TEXT  is  an 
implied  a  rqument . 

b.  Functional  Description 

If  the  PROC  has  no  TEXT  this  function  returns. 
If  it  has  a  TEXT/  the  TEXT'S  in-memory  use  count  is 
decremented.  If  the  count  reaches  zero*  the  memory  occupied 
by  the  TEXT's  text  seqment  is  freed. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
checked. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 


H .   page  .c 


1.   ptbu i 1 d ( t ab , s i ze 1 / s i ze2 , ad) 
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a  .   Paramet  ers 

The  first  parameter  is  a  pointer  to  a  PAGET. 
The  next  two  oarameters  are  the  sizes  in  64-byte  blocks  of  a 
process's  data  and  stack.  The  last  oarameter  is  a  pointer 
to  an  array  containing  the  memory  physical  block  numbers  of 
a  process's  pages. 

b.  Functional  Description 

This  function  is  present  only  in  PSUNIX.  It 
puts  the  sizes  and  addresses  of  a  process's  pages  into  the 
PAGET.  The  order  within  the  PAGET  is  data  pages  first  from 
low  to  high  virtual  address  followed  by  stack  pages  from 
high  to  low  virtual  address.  Unused  PAGET  entries  are 
zeroed . 

c.  Returned  Values 


The  value   returned   by   this   function   is   not 


chec  ked . 


d.   Error  Conditions 

This  function  has  no  error  conditions. 

2.   pt s i ze ( t ab , s i ze 1 , s i ze2 ) 

a .   Paramet  ers 

The  first  parameter  is  a  pointer  to  a  PAGET. 
The  last  two  parameters  are  the  sizes  in  6^-byte  blocks  of  a 
process's  data  and  stack. 
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b.   Functional  Description 

This  function  is  present  only  in  PSUNIX.  It 
puts  page  sizes  into  the  PAGET.  The  order  of  sizes  within 
the  PAGET  is  data  pages  from  low  to  high  virtual  address 
followed  by  stack  pages  from  high  to  low  virtual  address. 

c  .   Ret  urned  Values 

The  value  returned  by  this  function  is  not 
chec  ked. 

d.   Error  Conaitions 

This  function  has  no  error  conditions. 

3.   pal loc(ptab/ds>ss»cont) 

a .  Paramet  ers 

The  first  parameter  is  a  pointer  to  a  PAGET. 
The  next  two  parameters  are  a  process's  data  segment  and 
stack  segment  sizes  in  64-byte  blocks.  The  last  parameter 
is  the  contiguity  flag. 

b.  Functional  Description 

This  function  is  present  only  in  PSUNIX.  It 
calls  "ptsize"  to  put  the  page  sizes  into  the  PAGET, 
allocates  main  memory  for  each  PAGET  page  with  a  nonzero 
size*  and  puts  the  starting  block  numbers  of  the  allocated 
memory  into  the  PAGET.  If  allocation  fails  for  any  page, 
all   memory   allocated   for   the   process   is  freed.   If  the 
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contiguity  flag  is  set*  contiguous  memory  is   allocated   for 
both  the  data  and  stack  oages. 

c  .   Ret  urned  Va 1 ues 

If  allocation  for  all  pages  is  successful /  minus 
one  is  returned.  If  allocation  fails  for  any  page/  zero  is 
returned . 

d.   Error  Conditions 

A  returned  value  of  zero  indicates  an  allocation 
error  to  the  caller. 

4.   pfree(tab) 

a  .   Pa  ramet  er s 

The  parameter  is  a  pointer  to  a  PAGET. 

b.  Functional  Description 

This  function  is  found  only  is  PSUNIX.  It  frees 
the  memory  allocated  to  the  oages  in  the  PAGET. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
chec  ked . 


d.   Error  Conditions 


This  function  has  no  error  conditions. 
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5.       pcopv (ot ab t nt ab  ) 

a .  Parameters 

The  first  parameter  is  a  pointer  to  the  origin 
PAGET.  The  second  parameter  is  a  pointer  to  the  destination 
PAGET. 

b.  Functional  Description 

This  function  is  present   only   in  PSUNIX.    It 

copies  pages  pointed  to  by  the  oriqin  PAGET  to  corresponding 

pages  pointed  to  by  the   destination   PAGET,  A   zero   page 

block   number   in   either  PAGET  terminates  the  copying.   The 

number  of  blocks  copied  per    cage    is  determined  by   the   size 
of  the  origin  page. 

c .  Returned  Va 1 ues 


The  value   returned   by   this   function   is   not 


checked. 


d.   Error  Conditions 


This  function  has  no  error  conditions. 


6 .   pra 1  1 oc (pr  ) 


a .   Paramet  ers 


The  parameter  is   a   pointer   to   a   PRCC.    The 
PROC ' s  TEXT  is  an  imolied  input. 
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b.   Functional  Descriot  ion 

This  function  is  present  only  in  SUNIX  and 
PSUNIX.  It  acquires  memory  for  the  process's  UVECTOR*  data 
segment*  stack  segment*  and/  if  necessary*  shared  text 
segment.  Space  for  the  text  segment  is  acquired  only  if  the 
text  is  not  main  memory  resident.  If  any  allocation  fails* 
all  memory  previously  allocated  is  freed. 

c  .   Ret  urned  Values 

If  all  allocations  are  successful*  the  memory 
block  number  of  the  first  block  allocated  for  the  UVECTOR  is 
returned.   If  any  allocation  fails*  zero  is  returned. 

d.   Error  Conaitions 


A  return  value  of  zero  indicates  an    error  to  the 


ca 1 1 er 


7.   pswaD ( daddr * t ab * num* f 1 ag ) 

a .  Paramet  ers 

The  first  parameter  is  a  bloc*  number  on  the 
swap  device.  The  second  parameter  is  a  pointer  to  a  PAGET. 
The  third  parameter  is  the  number  of  Dages  to  swap.  The 
last  parameter  is  the  read-write  flag. 

b.  Functional  Description 

This  function  is  present  only  in  PSUNlX.  It 
swaps   the  indicated  number  of  pages  to  or  from  main  memory. 
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If  the  read-write  flag  is  set »  the  pages   are  swapped   into 

the   memory   locations  specified  by  the  PAGET.  If  it  is  not 

set*  the  pages  are  swapped  to  the  swap  device  beginning   at 
the  specified  block  number. 

c.  Returned  Values 

The  value  returned  by  this  function  is  not 
chec  ked. 

d.  Error  Conditions 

This  function  has  no  error  conditions. 
8 .   prswap ( ro ) 

a .  Paramet  ers 

The  parameter  is  a  pointer  to  a  PPOC.  The 
PROC's  TEXT  is  an  imolied  input, 

b.  Functional  DescriDtion 

This  function  is  present  only  in  SUNIX  and 
PSUNIX.  It  swaos  a  process's  UVECTOR/  data  segment/  stack 
segment/  and/  if  necessary/  text  segment  into  main  memory. 

c  .   Returned  Val ues 

The  value  returned  by  this  function  is  not 
chec  ked . 
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d.   Error  Conaitions 

If  an  input  error  occurs  during  the  swap/  the 
message  "swap  error"  will  be  sent  to  the  console  and  the 
system  will  crash. 

I .   b  i  o  .  c 

1.   physioCstrat,  abp,  dev,  rw) 

a .  Pa  rame t  e  r s 

The  first  parameter  is  a  Dointer  to  the  I/O 
initiation  routine  routine  for  the  device  to  be  used.  The 
second  parameter  is  to  a  buffer  header  that  contains  control 
information  about  the  I/O  ooerat ion  to  be  performed.  The 
third  parameter  is  the  device  identifier.  The  fourth 
parameter  is  a  read/write  flag. 

b.  Functional  Description 

This  function  computes  and  validates  the 
physical  address  of  an  I/O  area  within  the  User  address 
soace.  If  the  address  is  valid,  this  function  calls  the  I/O 
initiation  routine  to  start  the  I/O  operation.  In  PSUNIX, 
this  function  determines  if  the  I/O  area  crosses  a  page 
boundary.  If  it  does  cross  a  boundary,  this  function  calls 
"  C  o  n  t  i  g  (  )  "  to  make  the  reauesting  orocess  contiguous. 
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c  .   Ret  urned  Va  1 ues 


chec  ked . 


The  values  returned  by   this   function   are   not 


d.   Error  Conditions 


If  an  I/O   error   occurs   or    the    requested 

operation   is  not  valid/  an  error  condition  is  signaled  by 

setting  a   bit  in  u«-uerror   in   the   reauesting   process's 
UVECTOR. 


APPENDIX  C:  SYSTEM  BENCHMARKS 


A.   BENCH1 

chdir  /usr/emery 

sh  old 

chdir  ken 

cc  -0  -c  s I d  .c 

cd  .  . 

cd  dmr 

ed  ipc.c  </us r /bene h /edcmd  >/dev/nul1 

chdir  /us  r /bene  h 

cc  -0  r f test  .c 

bas  t owe r< t ower i n>/dev /nu 11 

od   /us r/sy s/con f /m45  .  s  >/dev/nul 1 

cd  /unix  /dev/null 

chdir  /bin 

sum  *>/dev/nu 1 1 

wa  i  t 

chdir  /us r /emery /ken 

rm  s 1 p  .  o 

chdir  /us  r/bench 

rm  a .out 


B.   BENCH2 

chdir  /usr/emery 

sh  old& 

chdir  ken 

cc  -0  -c  s 1 p  .c& 

cd  .  . 

cd  dmr 

ed  ipc.c  </us r /bene h/edemd  >/dev/nu11& 

chdir  /usr /bene  h 

cc  -0  r f  test .c& 

bas  t owe r< t owe r i n>/dev/nu 1  1  & 

od   /usr/sys/con f /m45 . s  >/dev/null& 

cp  /unix  /dev/nul 1& 

chdir  /bin 

sum  *>/dev/nu 1  1  & 

wa  i  t 

chdir  /us r /eme ry /ken 

rm  s 1 p  .  o 

chdir  /usr /Dene h 

rm  a .out 
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